|
Software architecture description is the set of practices for expressing, communicating and analysing software architectures (also called architectural rendering), and the result of applying such practices through a work product expressing a software architecture (ISO/IEC/IEEE 42010). Architecture descriptions (ADs) are also sometimes referred to as ''architecture representations'', ''architecture specifications''〔Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture". ACM SIGSOFT Software Engineering Notes 17 (4): 40. doi:10.1145/141874.141884〕 or ''software architecture documentation''. == Concepts == Architecture description defines the practices, techniques and types of representations used by software architects to record a software architecture. Architecture description is largely a modeling activity (Software architectural model). Architecture models can take various forms, including text, informal drawings, diagrams or other formalisms (modeling language). An architecture description will often employ several different ''model kinds'' to effectively address a variety of audiences, the ''stakeholders'' (such as end users, system owners, software developers, system engineers, program managers) and a variety of architectural ''concerns'' (such as functionality, safety, delivery, reliability, scalability). Often, the models of an architecture description are organized into ''multiple views'' of the architecture such that "each () addresses specific concerns of interest to different stakeholders of the system".〔P. B. Kruchten, "The '4+1' view model of architecture," IEEE Software, vol. 12, no. 6, pp. 42–50, November 1995〕 An ''architecture viewpoint'' is a way of looking at a system (RM_ODP). Each view in an architecture description should have a viewpoint documenting the concerns and stakeholders it is addressed to, and the model kinds, notations and modeling conventions it utilizes (ISO/IEC/IEEE 42010). The use of multiple views, while effective for communicating with diverse stakeholders and recording and analyzing diverse concerns, does raise potential problems: since views are typically not independent, the potential for overlap means there may be redundancy or inconsistency between views of a single system.〔A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, and M. Goedicke. Viewpoints: A framework for integrating multiple perspectives in system development. International Journal of Software Engineering and Knowledge Engineering, 2(1):31-58, 1992.〕 Various mechanisms can be used to define and manage ''correspondences'' between views to share detail, to reduce redundancy and to enforce consistency. A common misunderstanding about architecture descriptions is that ADs only discuss "technical issues", but ADs need to address issues of relevance to many stakeholders. Some issues are technical; many issues are not: ADs are used to help architects, their clients and others manage cost, schedule and process. A related misunderstanding is that ADs only address the ''structural'' aspects of a system. However, this rarely satisfies the stakeholders, whose concerns often include structural, behavioral, aesthetic, and other "extra-functional" concerns. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Software architecture description」の詳細全文を読む スポンサード リンク
|